The vendor_id for the Basic Data Format Descriptor Block is 0, defined as KHR_DF_VENDORID_KHRONOS in khr_df_vendorid_e.

The descriptor_type for the Basic Data Format Descriptor Block is 0, a value reserved in khr_df_khr_descriptortype_e (the enumeration of Khronos-specific descriptor types) as KHR_DF_KHR_DESCRIPTORTYPE_BASICFORMAT.

The version_number relating to the Basic Data Format Descriptor Block as described in this specification is 1.

The size of the Basic Data Format Descriptor Block depends on the number of samples contained within it. The memory requirements for this format are 24 bytes of shared data plus 16 bytes per sample. The descriptor_block_size is measured in bytes.

The color_model determines the set of color (or other data) channels which may be encoded within the data, though there is no requirement that all of the possible channels from the color_model be present. Most data fits into a small number of common color models, but compressed texture formats each have their own color model enumeration. Note that the data need not actually represent a color — this is just the most common type of content using this descriptor. Some standards use color container for this concept.

The available color models are described in the khr_df_model_e enumeration, and are represented as an unsigned 8-bit value.

Note that the numbering of the component channels is chosen such that those channel types which are common across multiple color models have the same enumeration value. That is, alpha is always encoded as channel ID 15, depth is always encoded as channel ID 14, and stencil is always encoded as channel ID 13. Luma/Luminance is always in channel ID 0. This numbering convention is intended to simplify code which can process a range of color models. Note that there is no guarantee that models which do not support these channels will not use this channel ID. Particularly, RGB formats do not have luma in channel 0, and a 16-channel undefined format is not obligated to represent alpha in any way in channel number 15.

The value of each enumerant is shown in parentheses following the enumerant name.

KHR_DF_MODEL_YUVSDA (= 2)

This color model represents color differences with three channels, nominally luma (Y') and two color-difference chroma channels, U (C_B) and V (C_R), supplemented by channels for alpha, depth and stencil, as shown in Table 13, “Basic Data Format YUVSDA channels”. These formats are distinguished by C_B and C_R being a delta between the Y' channel and the blue and red channels respectively, rather than requiring a full color matrix. The conversion between Y’C_BC_R and RGB color spaces is defined in this case by the choice of value in the color_primaries field as described in Section 20.1, “Y’C_BC_R color model”.

	Most single-channel luma/luminance monochrome data formats should select KHR_DF_MODEL_YUVSDA and use only the Y channel, unless there is a reason to do otherwise.

Table 13. Basic Data Format YUVSDA channels

Channel number	Name		Description
0	KHR_DF_CHANNEL_YUVSDA_Y		Y/Y' (luma/luminance)
1	KHR_DF_CHANNEL_YUVSDA_CB		CB (alias for U)
1	KHR_DF_CHANNEL_YUVSDA_U		U (alias for CB)
2	KHR_DF_CHANNEL_YUVSDA_CR		CR (alias for V)
2	KHR_DF_CHANNEL_YUVSDA_V		V (alias for CR)
13	KHR_DF_CHANNEL_YUVSDA_STENCIL		Stencil
14	KHR_DF_CHANNEL_YUVSDA_DEPTH		Depth
15	KHR_DF_CHANNEL_YUVSDA_ALPHA		Alpha (transparency)

Terminology for this color model is often abused. This model is based on the idea of creating a representation of monochrome light intensity as a weighted average of color channels, then calculating color differences by subtracting two of the color channels from this monochrome value. Proper names vary for each variant of the ensuing numbers, but “YUV” is colloquially used for all of them. In the television standards from which this terminology is derived, Y’CBCR is more formally used to describe the representation of these color differences. See Section 20.1, “Y’CBCR color model” for more detail.

It is not sufficient to define a buffer as containing, for example, additive primaries. Additional information is required to define what “red” is provided by the “red” channel. A full definition of primaries requires an extension which provides the full color space of the data, but a subset of common primary spaces can be identified by the khr_df_primaries_e enumeration, represented as an unsigned 8-bit integer value.

More information about color primaries is provided in Section 19, “Color primaries”.

Many color representations contain a non-linear transfer function which maps between a linear (intensity-based) representation and a more perceptually-uniform encoding. Common transfer functions are encoded in the khr_df_transfer_e enumeration and represented as an unsigned 8-bit integer. A fully-flexible transfer function requires an extension with a full color space definition. Where the transfer function can be described as a simple power curve, applying the function is commonly known as “gamma correction”. The transfer function is applied to a sample only when the sample’s KHR_DF_SAMPLE_DATATYPE_LINEAR bit is 0; if this bit is 1, the sample is represented linearly irrespective of the transfer_function.

When a color model contains more than one channel in a sample and the transfer function should be applied only to a subset of those channels, the convention of that model should be used when applying the transfer function. For example, ASTC stores both alpha and RGB data but is represented by a single sample; in ASTC, any sRGB transfer function is not applied to the alpha channel of the ASTC texture. In this case, the KHR_DF_SAMPLE_DATATYPE_LINEAR bit being zero means that the transfer function is “applied” to the ASTC sample in a way that only affects the RGB channels. This is not a concern for most color models, which explicitly store different channels in each sample.

If all the samples are linear, KHR_DF_TRANSFER_LINEAR should be used. In this case, no sample should have the KHR_DF_SAMPLE_DATATYPE_LINEAR bit set.

The enumerant value for each of the following transfer functions is shown in parentheses alongside the title.

KHR_DF_TRANSFER_NTSC (= 4)

This value represents the non-linear transfer function defined by the original NTSC television broadcast specification. This is described in Section 18.8, “Legacy NTSC transfer functions”.

	More recent formulations of this transfer functions, such as that defined in SMPTE 170M-2004, use it ITU formulation described above.

The format supports some configuration options in the form of boolean flags; these are described in the khr_df_flags_e enumeration and represented in an unsigned 8-bit integer value.

The texel_block_dimensions define the number of coordinates covered by the repeating block described by the samples. Four separate values, represented as unsigned 8-bit integers, are supported, corresponding to successive dimensions. The Basic Data Format Descriptor Block supports up to four dimensions of encoding within a texel block, supporting, for example, a texture with three spatial dimensions and one temporal dimension. Nothing stops the data structure as a whole from having higher dimensionality: for example, a two-dimensional texel block can be used as an element in a six-dimensional look-up table.

The value held in each of these fields is one fewer than the size of the block in that dimension — that is, a value of 0 represents a size of 1, a value of 1 represents a size of 2, etc. A texel block which covers fewer than four dimensions should have a size of 1 in each dimension that it lacks, and therefore the corresponding fields in the representation should be 0.

For example, a Y’C_BC_R 4:2:0 representation may use a Texel Block of 2×2 pixels in the nominal coordinate space, corresponding to the four Y' samples, as shown in Table 27, “Example Basic Data Format texel_block_dimensions for Y’C_BC_R 4:2:0”. The texel block dimensions in this case would be 2×2×1×1 (in the X, Y, Z and T dimensions, if the fourth dimension is interpreted as T). The texel_block_dimensions_[0..3] values would therefore be:

The Basic Data Format Descriptor divides the image into a number of planes, each consisting of an integer number of consecutive bytes. The requirement that planes consist of consecutive data means that formats with distinct subsampled channels — such as Y’C_BC_R 4:2:0 — may require multiple planes to describe a channel. A typical Y’C_BC_R 4:2:0 image has two planes for the Y' channel in this representation, offset by one line vertically.

The use of byte granularity to define planes is a choice to allow large texels (of up to 255 bytes). A consequence of this is that formats which are not byte-aligned on each addressable unit, such as 1-bit-per-pixel formats, need to represent a texel block of multiple samples, contained within a.

A maximum of eight independent planes is supported in the Basic Data Format Descriptor. Formats which require more than eight planes — which are rare — require an extension.

The bytes_plane_[0..7] fields each contain an unsigned 8-bit integer which represents the number of bytes which that plane contributes to the format. The first field which contains the value 0 indicates that only a subset of the 8 possible planes are present; that is, planes which are not present should be given the bytes_plane value of 0, and any bytes_plane values after the first 0 are ignored. If no bytes_plane value is zero, 8 planes are considered to exist.

As an exception, if bytes_plane_0 has the value 0, the first plane is considered to hold indices into a color palette, which is described by one or more additional planes and samples in the normal way. The first sample in this case should describe a 1×1×1×1 texel holding an unsigned integer value. The number of bits used by the index should be encoded in this sample, with a maximum value of the largest palette entry held in sample_upper. Subsequent samples describe the entries in the palette, starting at an offset of bit 0. Note that the texel block in the index plane is not required to be byte-aligned in this case, and will not be for paletted formats which have small palettes. The channel type for the index is irrelevant.

For example, consider a 5-color paletted texture which describes each of these colors using 8 bits of red, green, blue and alpha. The color model would be RGBSDA, and the format would be described with two planes. bytes_plane_0 would be 0, indicating the special case of a palette, and bytes_plane_1 would be 4, representing the size of the palette entry. The first sample would then have a number of bits corresponding to the number of bits for the palette — in this case, three bits, corresponding the requirements of a 5-color palette. The sample_upper value for this sample is 4, indicating only 5 palette entries. Four subsequent samples represent the red, green, blue and alpha channels, starting from bit 0 as though the index value were not present, and describe the contents of the palette. The full data format descriptor for this example is provided in Table 104, “Four co-sited 8-bit channels in the sRGB color space described by an 5-entry, 3-bit palette” as one of the example format descriptors.

The layout and position of the information within each plane is determined by a number of samples, each consisting of a single channel of data and with a single corresponding position within the texel block, as shown in Table 28, “Basic Data Format Descriptor Sample Information”.

The bytes from the plane data contributing to the format are treated as though they have been concatenated into a bit stream, with the first byte of the lowest-numbered plane providing the lowest bits of the result. Each sample consists of a number of consecutive bits from this bit stream.

If the content for a channel cannot be represented in a single sample, for example because the data for a channel is non-consecutive within this bit stream, additional samples with the same coordinate position and channel number should follow from the first, in order increasing from the least significant bits from the channel data.

Note that some native big-endian formats may need to be supported with multiple samples in a channel, since the constituent bits may not be consecutive in a little-endian interpretation. There is an example, Table 106, “565 RGB format as represented on a big-endian architecture”, in the list of format descriptors provided. In this case, the sample_lower and sample_upper fields for the combined sample are taken from the first sample to belong uniquely to this channel/position pair.

By convention, to avoid aliases for formats, samples should be listed in order starting with channels at the lowest bits of this bit stream. Ties should be broken by increasing channel type id, as shown in Table 110, “Intensity-alpha format showing aliased samples”.

The number of samples present in the format is determined by the descriptor_block_size field. There is no limit on the number of samples which may be present, other than the maximum size of the Data Format Descriptor Block. There is no requirement that samples should access unique parts of the bit-stream: formats such as combined intensity and alpha, or shared exponent formats, require that bits be reused. Nor is there a requirement that all the bits in a plane be used (a format may contain padding).

While it is not expected that every new container will have a unique data descriptor or that analysis of the data format descriptor will be on a critical path in an application, it is still expected that comparison between formats may be time-sensitive. The data format descriptor is designed to allow relatively efficient queries for subsets of properties, to allow a large number of format descriptors to be stored, and to be amenable to hardware interpretation or processing in shaders. These goals preclude a text-based representation such as an XML schema.

Formats in FourCC.org do not describe in detail sufficient information for many APIs, and are sometimes inconsistent.

Enumerations are fast and easy to process, but are limited in that any software can only be aware of the enumeration values in place when it was defined. Software often behaves differently according to properties of a format, and must perform a look-up on the enumeration — if it knows what it is — in order to change behaviors. A descriptive format allows for more flexible software which can support a wide range of formats without needing each to be listed, and simplifies the programming of conditional behavior based on format properties.

Khronos supports multiple standards that have a range of internal data representations. There is no requirement that this standard be used specifically with other Khronos standards, but it is hoped that multiple Khronos standards may use this specification as part of a consistent approach to inter-standard operation.

While a library may not use all the data provided in the data format descriptor that is described within this standard, it is common for users of data — particularly pixel-like data — to have additional requirements. Capturing these requirements portably reduces the need for additional metadata to be associated with a proprietary descriptor. It is also common for additional functionality to be added retrospectively to existing libraries — for example, Y’C_BC_R support is often an afterthought in rendering APIs. Having a consistent and flexible representation in place from the start can reduce the pain of retrofitting this functionality.

Note that there is no expectation that the format descriptor from this standard be used directly, although it can be. The impact of providing a mapping between internal formats and format descriptors is expected to be low, but offers the opportunity both for simplified access from software outside the proprietary library and for reducing the effort needed to provide a complete, unambiguous and accurate description of a format in human-readable terms.

There is a trade-off between size and decoding effort. It is assumed that data which occupies the same 32-bit word may need to be tested concurrently, reducing the cost of comparisons. When transferring data formats, the packing reduces the overhead. Within these constraints, it is intended that most data can be extracted with low-cost operations, typically being byte-aligned (other than sample flags) and with the natural alignment applied to multi-byte quantities.

For simple ASCII content, there is no reason that plain text could not be described in some way, and this may be useful for image formats that contain comment sections. However, since many multilingual text representations do not have a fixed character size, this use is not seen as an obvious match for this standard.

Each $4 \times 4$ block of texels consists of 64 bits of RGB image data.

Each RGB image data block is encoded as a sequence of 8 bytes, called (in order of increasing address):

The 8 bytes of the block are decoded into three quantities:

color0 and color1 are 16-bit unsigned integers that are unpacked to RGB colors RGB0 and RGB1 as though they were 16-bit packed pixels with the R channel in the high 5 bits, G in the next 6 bits and B in the low 5 bits.

bits is a 32-bit unsigned integer, from which a two-bit control code is extracted for a texel at location $(x,y)$ in the block using:

where bit 31 is the most significant and bit 0 is the least significant bit.

The RGB color for a texel at location $(x,y)$ in the block is given in Table 30, “Block decoding for BC1”.

Arithmetic operations are done per component, and BLACK refers to an RGB color where red, green, and blue are all zero.

Since this image has an RGB format, there is no alpha component and the image is considered fully opaque.

Each $4\times 4$ block of texels consists of 64 bits of RGB image data and minimal alpha information. The RGB components of a texel are extracted in the same way as BC1 with no alpha.

The alpha component for a texel at location $(x,y)$ in the block is given by Table 31, “BC1 with alpha”.

The red, green, and blue components of any texels with a final alpha of 0 should be encoded as zero (black).

Each $4\times 4$ block of texels consists of 64 bits of uncompressed alpha image data followed by 64 bits of RGB image data.

Each RGB image data block is encoded according to the BC1 formats, with the exception that the two code bits always use the non-transparent encodings. In other words, they are treated as though color0 > color1, regardless of the actual values of color0 and color1.

Each alpha image data block is encoded as a sequence of 8 bytes, called (in order of increasing address):

The 8 bytes of the block are decoded into one 64-bit integer:

alpha is a 64-bit unsigned integer, from which a four-bit alpha value is extracted for a texel at location $(x,y)$ in the block using:

where bit 63 is the most significant and bit 0 is the least significant bit.

The alpha component for a texel at location $(x,y)$ in the block is given by $alpha(x,y)\over 15$ .

Each $4\times 4$ block of texels consists of 64 bits of compressed alpha image data followed by 64 bits of RGB image data.

Each RGB image data block is encoded according to the BC1 formats, with the exception that the two code bits always use the non-transparent encodings. In other words, they are treated as though color0 > color1, regardless of the actual values of color0 and color1.

Each alpha image data block is encoded as a sequence of 8 bytes, called (in order of increasing address):

The $alpha_0$ and $alpha_1$ are 8-bit unsigned bytes converted to alpha components by multiplying by $1\over 255$ .

The 6 bits bytes of the block are decoded into one 48-bit integer:

bits is a 48-bit unsigned integer, from which a three-bit control code is extracted for a texel at location $(x,y)$ in the block using:

where bit 47 is the most-significant and bit 0 is the least-significant bit.

The alpha component for a texel at location $(x,y)$ in the block is given by Table 32, “Alpha encoding for BC3 blocks”.

Each $4 \times 4$ block of texels consists of 64 bits of unsigned red image data.

Each red image data block is encoded as a sequence of 8 bytes, called (in order of increasing address):

The 6 $bits_*$ bytes of the block are decoded into a 48-bit bit vector:

$red_0$ and $red_1$ are 8-bit unsigned integers that are unpacked to red values $RED_0$ and $RED_1$ .

$bits$ is a 48-bit unsigned integer, from which a three-bit control code is extracted for a texel at location $(x,y)$ in the block using:

where bit 47 is the most significant and bit 0 is the least significant bit.

The red value $R$ for a texel at location $(x,y)$ in the block is given by Table 33, “Block decoding for BC4”.

$RED_{min}$ and $RED_{max}$ are 0.0 and 1.0 respectively.

Since the decoded texel has a red format, the resulting RGBA value for the texel is $(R,0,0,1)$ .

Each $4 \times 4$ block of texels consists of 64 bits of signed red image data. The red values of a texel are extracted in the same way as BC4 unsigned except $red_0$ , $red_1$ , $RED_0$ , $RED_1$ , $RED_{min}$ , and $RED_{max}$ are signed values defined as follows:

$red_0$ and $red_1$ are 8-bit signed (twos complement) integers.

CAVEAT for signed $red_0$ and $red_1$ values: the expressions $red_0 > red_1$ and $red_0 \leq red_1$ above are considered undefined (read: may vary by implementation) when $red_0 = -127$ and $red_1 = -128$ . This is because if $red_0$ were remapped to -127 prior to the comparison to reduce the latency of a hardware decompressor, the expressions would reverse their logic. Encoders for the signed red-green formats should avoid encoding blocks where $red_0 = -127$ and $red_1 = -128$ .

Each $4 \times 4$ block of texels consists of 64 bits of compressed unsigned red image data followed by 64 bits of compressed unsigned green image data.

The first 64 bits of compressed red are decoded exactly like BC4 unsigned above.

The second 64 bits of compressed green are decoded exactly like BC4 unsigned above except the decoded value $R$ for this second block is considered the resulting green value $G$ .

Since the decoded texel has a red-green format, the resulting RGBA value for the texel is $(R,G,0,1)$ .

Each $4 \times 4$ block of texels consists of 64 bits of compressed signed red image data followed by 64 bits of compressed signed green image data.

The first 64 bits of compressed red are decoded exactly like BC4 signed above.

The second 64 bits of compressed green are decoded exactly like BC4 signed above except the decoded value $R$ for this second block is considered the resulting green value $G$ .

Since this image has a red-green format, the resulting RGBA value is $(R,G,0,1)$ .

Each $4 \times 4$ block of texels consists of 128 bits of RGBA image data, of which the RGB components may be encoded linearly or with the sRGB transfer function.

Each block contains enough information to select and decode a pair of colors called endpoints, interpolate between those endpoints in a variety of ways, then remap the result into the final output.

Each block can contain data in one of eight modes. The mode is identified by the lowest bits of the lowest byte. It is encoded as zero or more zeros followed by a one. For example, using x to indicate a bit not included in the mode number, mode 0 is encoded as xxxxxxx1 in the low byte in binary, mode 5 is xx100000, and mode 7 is 10000000. Encoding the low byte as zero is reserved and should not be used when encoding a BPTC texture.

All further decoding is driven by the values derived from the mode listed in Table 36, “Mode-dependent BPTC parameters.” and Table 37, “The full descriptions of the BPTC mode columns are as follows”. The fields in the block are always in the same order for all modes. Starting at the lowest bit after the mode and going up, these fields are: partition number, rotation, index selection, color, alpha, per-endpoint P-bit, shared P-bit, primary indices, and secondary indices. The number of bits to be read in each field is determined directly from the table.

Each block can be divided into between 1 and 3 groups of pixels with independent compression parameters called subsets. A texel in a block with one subset is always considered to be in subset zero. Otherwise, a number determined by the number of partition bits is used to look up in Table 38, “Partition table for BPTC 2 subset, with the 4×4 block of values for each partition index value” or Table 39, “Partition table for BPTC 3 subset, with the 4×4 block of values for each partition index value” for 2 and 3 subsets respectively. This partitioning is indexed by the X and Y within the block to generate the subset index.

Each block has two colors for each subset, stored first by endpoint, then by subset, then by color. For example, a format with two subsets and five color bits would have five bits of red for endpoint 0 of the first subset, then five bits of red for endpoint 1, then the two ends of the second subset, then green and blue stored similarly. If a block has non-zero alpha bits, the alpha data follows the color data with the same organization. If not, alpha is overridden to 1.0. These bits are treated as the high bits of a fixed-point value in a byte. If the format has a shared P-bit, there are two bits for endpoints 0 and 1 from low to high. If the format has a per-endpoint P-bits, then there are $2 \times subsets$ P-bits stored in the same order as color and alpha. Both kinds of P-bits are added as a bit below the color data stored in the byte. So, for a format with 5 red bits, the P-bit ends up in bit 2. For final scaling, the top bits of the value are replicated into any remaining bits in the byte. For the preceding example, bits 6 and 7 would be written to bits 0 and 1.

The endpoint colors are interpolated using index values stored in the block. The index bits are stored in x-major order. Each index has the number of bits indicated by the mode except for one special index per subset called the anchor index. Since the ordering of the endpoints is unimportant, we can save one bit on one index per subset by ordering the endpoints such that the highest bit is guaranteed to be zero. In partition zero, the anchor index is always index zero. In other partitions, the anchor index is specified by Table 40, “BPTC anchor index values for the second subset of two-subset partitioning. Values run right, then down.”, Table 41, “BPTC anchor index values for the second subset of three-subset partitioning. Values run right, then down.”, and Table 42, “BPTC anchor index values for the third subset of three-subset partitioning. Values run right, then down.”. If secondary index bits are present, they are read in the same manner. The anchor index information is only used to determine the number of bits each index has when it’s read from the block data.

The endpoint color and alpha values used for final interpolation are the decoded values corresponding to the applicable subset as selected above. The index value for interpolating color comes from the secondary index for the texel if the format has an index selection bit and its value is one and from the primary index otherwise. The alpha index comes from the secondary index if the block has a secondary index and the block either doesn’t have an index selection bit or that bit is zero and the primary index otherwise.

Interpolation is always performed using a 6-bit interpolation factor. The effective interpolation factors for 2-, 3-, and 4-bit indices are given in Table 34, “BPTC interpolation factors”.

The interpolation results in an RGBA color. If rotation bits are present, this color is remapped according to Table 35, “BPTC Rotation bits”.

These 8-bit values should be interpreted as RGBA 8-bit normalized channels, either linearly encoded or with the sRGB transfer function.